Okay.
In this lecture, I'm going to show you the event data type role box has been designed to be event driven,
meaning that code only executes when an event fires.
And this is very performant.
This means that you should never be polling for some condition or event to happen as that's just a complete
waste of resources.
You should never, ever have a loop in your game that just sits there and yields until some condition
or event happens.
That's just dumb.
As an example here I have this repeat loop that's constantly yielding until some condition or an event
fires to circumvent this.
Roadblocks has the event data type which allows you to connect functions to the event that get executed
when the event fires.
So here in my game I have this part here called Event Part, and this part has several events that I
can connect to and utilize.
One of these events is called the Touched event, and it gets fired whenever this part gets touched
by another part.
Any functions connected to the event are called listeners, and when they get fired and executed, they're
known as event handlers.
So to use this event, I already have a reference to my part in the workspace.
So I will index my part and get access to the touched event right here.
Now I can use another function that's called Connect.
And allows me to pass a function that connects to this event.
And when the event fires, it executes the function.
So I will create a lambda function here, an anonymous function.
Remember, there is no identifier, so I can't call this function from anywhere else.
It just belongs to this event.
And then I can print the name of the part that touched this other part, and it gets automatically passed
to my lambda function as an argument.
So I'll just give it a name like other part.
And then I can print the name of this other part.
So now if I go into my game and I actually play my game, doing play, it spawns my character in.
There we go.
I can go run over to my part.
Looks like Roblox had an error there.
And when I touched my part, it should fire the name of one of my limbs that touched the part.
Here we go.
Right.
Lower leg.
Right upper leg and right foot.
And then I can keep jumping on it.
So, like, I got a humanoid part touching it.
So you see all the stuff printing when I touch the part.
Now, another event I want to talk about is the child and descendent added events.
And basically these events get fired when an instance becomes a child of the object you're listening
to.
The child added event is specifically for listening when a non nested child gets added to my part.
So for example, in my part here, if I added some kind of instance like a texture, the event will
get fired.
And it would say, This texture instance got added to my part.
If I added another child whose parent was the texture, like, I'll add, I don't know, an animation.
Then the child added event would get fired for this texture, but it wouldn't get it fired for this
part.
If I wanted to listen to every single nested child get added to my part, then I would use the descendant
added event and I'll show it here real quick.
So reference my part again and then find the child added event and then connect a lambda function to
it.
And of course, this event passes a new child.
And then I'll just print the name of the child.
And then for the descendent added event, connect another function and get the descendant.
And then I'll just print the name of the descendant.
Now my script.
I'm going to create a for loop that just loops twice.
And I'm going to create a new part.
Using the instance, start new function and make a new part.
Not particle emitter, but a part.
And then the part, the name of this part will just be new part.
And I'll concatenate to the string I.
And then I'll set the parent of new part to be the part.
Now, the problem here is because I'm studying the parent of these new parts to the same part.
Both of these events will fire twice.
This is because the child added event will see both parts being added because there are no nested children.
And this event will also see both children being added because it's looking for every single descendant.
Now, if I want this event to fire twice, but only have this event fire once, I need to make one of
these new parts nested or basically the parent of one of the new parts needs to be the other new part.
And to do that, I have this neat little function I can access.
And it's called the Fine First Child, which is a and it returns.
The first child of this function can fine.
That is a child of this part that belongs to particular class.
In this case, I want to do the base part class because these new instances are parts.
And if it can't find a part because through the first iteration there will be no children to our part
that are parts.
Then I can use the or operator here the or statement and just pass part.
So through the first iteration of this loop, this will result in nil.
So it will be falsey.
So it'll default to parenting to part.
But once we create this new part in our part, so when a new part becomes a child of our event part,
I'll just make one here.
So we have a new child in here through the second iteration.
When this function gets run again, it'll see this new part exists, so then it will set the parent
to this new part.
So the second part will be the parent of this part.
And now we have a nested child that is part of our event, part.
So this means that the descendant added event will see both parts being added, but the child added
won't be able to see both parts.
It'll only see the first one.
Let's run the game to confirm this.
Perfect.
You see that the child added event saw a new part one and so did the descendant added event.
But then when new part two was created, it got parented to new part one, so only the descendant added
event saw it and not the child added event.
So this is just a quick overview of the event data type and how you can utilize them in your game.
The event data type is among the most common data types you will be using in Roblox.